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Summary 

The Planview Graphical User Interface (PGUI) is the 
primary display of air traffic for the Conflict Prediction 
and Trial Planning function of the Center TRACON 
Automation System. The PGUI displays air traffic infor- 
mation that assists the user in making decisions related to 
conflict detection, conflict resolution, and traffic flow 
management. The intent of this document is to outline 
the human factors issues related to the design of the con- 
flict prediction and trial planning portions of the PGUI, 
document all human factors related design changes made to 
the PGUI from December 1996 to September 1997, and 
outline future plans for the ongoing PGUI design. 

Introduction 

The Conflict Prediction and Trial Planning (CPTP) 
function has been implemented as a software process 
within the Center TRACON Automation System 
(CTAS). The CTAS system provides real-time informa- 
tion and advisories to air traffic controllers to help them 
improve the efficiency of the airspace system. CPTP uses 
the trajectory synthesis capability of CTAS to generate 
predicted route trajectories for the conflict search and trial 
planning processes (ref. 1). 

The purpose of this memorandum is to address the design 
of CTAS Planview Graphical User Interface (PGUI) ele- 
ments used in the CPTP functionality. The basic PGUI 
display included a scaleable representation of the airspace 
with jet routes, waypoints, sector boundaries, and aircraft 
symbols with their corresponding flight data blocks 
(FDBs). As the conflict prediction capability was insti- 
tuted within the CTAS system, a conflict list displaying 
the aircraft pairs predicted to be in conflict and a limited 
graphical representation of conflict geometry was added to 
the PGUI. 

The PGUI also displayed several large panels (accessed via 
functions keys) for setting the conflict probe parameters as 
well as all the other PGUI parameters. All of the setup 
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panels and functions of the PGUI had been designed as the 
sole engineering prototype interface for the CTAS func- 
tionality. As with most engineering prototypes, it was 
not, nor should it have been, an interface appropriate for 
use by an end user. This document outlines the process by 
which the engineering CTAS PGUI was evolved into a 
PGUI more appropriate for use by an end user. 

Desired CPTP PGUI Capability 

The human factors team conducted a preliminary famili- 
arization and evaluation process during which a number 
of broad design issues were identified. The human factors 
concerns related to the CPTP PGUI design were as 
follows: 

1 . Color 

a. A color use philosophy did not exist. 

b. Color was not consistent. 

c. Color was used extensively and somewhat 
randomly, thus diluting the impact of its usage. 

d. Color use did not address the issue that control- 
lers are not currently screened for color blindness. 

e. Perceptually problematic colors such as saturated 
reds and blues were widely used. 

f. Text and graphical information was generally 
presented in light shades against a black 
background. 

g. There was a hardware limitation of eight bit color 
and a software limitation of a three level color 
scheme with only three top level colors. 

2. Display parameters 

a. No philosophy regarding how and when the 
PGUI should constrain the user regarding setup 
of system parameters. 

b. Large display setup differences were common 
across users, thus confounding some of the 
computer human interface (CHI) issues. 



3. Global display 

a. Global commands for functions such as trend 
vectors, flight data blocks, range rings, and 
range/bearing required difficult to recall keyboard 
entries. 

b. Active aircraft inputs such as speed, altitude, and 
route changes were difficult to make. 

c. Track histories were not displayed in a format 
that used adequate update rates and symbology. 

d. Aircraft symbols were displayed using non- 
standard text symbology . 

e. Zoom and centering functions were very difficult 
to use, requiring excessive keyboard entries. 

f. General setup functionality was dispersed 
throughout a variety of function key panels. 

g. Help function was limited, outdated, and hard to 
understand. 

4. Conflict detection graphics 

a. Minimal graphical display of conflict informa- 
tion made it difficult for a user to determine 
which aircraft were in conflict and what the 
conflict geometry was. 

b. Limited text information further complicated the 
conflict detection task. 

5 . Conflict resolution 

a. Provision of only one trajectory per aircraft 
resulted in an inability to display an active 
trajectory during trial planning, resulting in a 
loss of situation awareness. 

b. Complex and difficult to recall keyboard entries 
were required for active inputs for conflict 
resolution. 

c. No easily identifiable way (graphic or textual) to 
determine whether a conflict resolution has been 
identified. 

d. Mode awareness of active versus trial plan modes 
was nonexistent. 

6. Text/Graphics presentation of information 

a. No reasoned approach to use of tabular versus 
graphical display of information. 

b. Initial display was heavily biased toward textual 
presentation of information. 

c. Graphical representation was unclear and hard to 
understand. 


7. Occlusion of traffic display 

a. Large setup panels and pop-up windows occlude 
the traffic display at the start of operation. 

b. Conflict prediction list can occlude traffic display 
during system use. 

8 . PGUI element update rates 

a. Various display elements update at obviously 
different rates. 

b. No indication to the user of any of the update rate 
values. 

9 . PGUI CPTP user documentation 

a. User manual was minimal, outdated, and 
inaccurate. 

b. No training material. 

PGUI Design Approach 

It is relatively easy to provide design suggestions in an 
ideal world of limitless resources. The more challenging 
situation is the application of sound principles in an 
environment that demands constant compromise in order 
to meet resource constraints and the limitations of exist- 
ing hardware and software architecture. Decisions of this 
sort were and are made on a daily basis during PGUI (and 
all CTAS related) design and implementation processes 
and required knowledge of system hardware and software 
as well as general human factors principles. 

It is important to realize that in the development of an 
automated system, an engineering interface will evolve 
that meets the initial prototyping needs of the researchers 
(the PGUI as it existed in November 1996 was such an 
engineering interface). The use, and therefore the design, 
of an engineering interface is likely to be quite different 
from the kind of CHI that will be demanded by an 
end user. 

There are principles of design that can be applied in the 
development of an end user CHI and it is important to 
realize that these principles might conflict with the 
personal preferences of individual researchers who are 
likely to have adapted to the engineering interface. It is 
also important to note that, while end user input is quite 
important in CHI design, end users are not qualified inter- 
face designers. An interface design will serve its purpose 
most effectively if it is designed using basic human per- 
formance and design principles as well as domain specific 
expert input and engineering expertise. The design process 
used in the implementation of the PGUI changes docu- 
mented here was arrived at through an interdisciplinary and 
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highly interactive and iterative process that included input 
from human factors, software development, and domain 
experts. 

The following is a summary of the design changes that 
were made in response to the PGUI human factors 
evaluation. Each item is referenced to the human factors 
concerns listed in the Desired Capability section above. 
Following this section is a complete history of the 
changes made to the CPTP PGUI that will provide the 
reader with much more detailed information about each 
of the design changes noted here. 

Color Redesign of PGUI 

(la-g) Development of a new color design for the PGUI 
was enabled by the implementation of a double 
buffer color infrastructure. The double buffer 
scheme provided access to 127 top level colors, 
which was enough color flexibility for the 
implementation of a total PGUI color redesign. 

Conflict Detection Graphics Enhancement 

(4a) The graphical conflict ambiguities were addressed 
by the addition of red conflict prediction lines 
that extended from the conflict aircraft to the 
point of first loss of separation. 

Conflict Resolution Enhancement 

(5a, b) A multitrajectory capability was designed and 
implemented by the engineering team that 
allowed the system to display both a trial plan 
trajectory that could be manipulated by the user 
and the active aircraft trajectory that displayed the 
actual position of the aircraft. Trial plan graphics 
were developed for altitude, speed, and vector 
changes using the new multiple trajectory 
capability. In addition to the multiple trajectory 
graphics, a panel was developed for use in trial 
planning inputs. This preliminary attempt at a 
“real” trial planning functionality allowed for 
situation awareness of the active trajectory while 
in trial planning mode and was the second large 
step in the evolution of the trial planning 
functionality. 

As trial planning functionality was tested and 
evaluated by human factors, engineering, and end 
user teams, there was a strong consensus reached 
that the functionality had to evolve to a point and 
click interface that would remove the end user’s 
hands from the keyboard. The point and click 
functionality was to be accessed through the 


relevant fields on the aircraft’s flight data block. 
This removed the need for the trial planning 
panel and related keyboard inputs. 

(5b) Simplification and linking of the capture 

waypoint and auxiliary waypoint functions were 
provided along with the simplification of the user 
input process for vectoring an aircraft. The 
purpose for these initial changes was to link 
functionality that was conceptually related and to 
take a first step in the evolution of a trial 
planning functionality. 

(5c) There was no easy way for the user to determine 
whether a predicted conflict in an active trajectory 
had been resolved. The initial solution was to put 
an “R” for resolved in the time slot of the 
conflict prediction list. Trial plan trajectory 
conflict status was displayed with the addition 
of a Trial Conflicts Panel. 

PGUI CPTP User Manual Updated 

(9a) The CPTP functionality and PGUI setup 

parameters were incorporated into a CPTP User’s 
Guide currently available in release 2.0. 

PGUI CPTP Training Material Developed 

(9b) A CPTP training packet was developed for use in 
training air traffic controllers at Ames Research 
Center and at air route traffic control center 
(ARTCC) facilities. 

Design History 

The intent of this section is to document all of the work 
conducted between December 1996 and September 1997 
on the CPTP PGUI and to provide some insight into the 
intent behind each of the design changes. 

December 1996 

Conflict detection graphics enhancement (4a)- The 
initial PGUI had minimal graphical and textual indication 
of a detected conflict. Graphical information consisted of 
small red asterisks marking the point of initial loss of 
separation accompanied by a textual listing of the con- 
flicting aircraft callsign above the asterisk. Consequently, 
it was difficult to determine which two aircraft were in 
conflict from either textual or graphical information. The 
textual presentation of conflict information was accom- 
plished by the addition of the conflict aircraft callsign 
displayed in red in the fourth line of the data block as 
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shown in figure 1. The fourth line was displayed by 
default as soon as the system identified a potential con- 
flict. If a flight data block was not already displayed for a 
conflict aircraft, the data block was displayed automati- 
cally. The purpose for this change was to provide a 
redundant textual conflict cue in addition to the conflict 
list panel shown in figure 2. 

The graphical conflict ambiguities were addressed by the 
addition of red conflict prediction lines that extended from 
the conflict aircraft to the point of first loss of separation 
as shown in figure 3. The red conflict lines were displayed 
when the user selected a conflict pair from the conflict list 
for further examination. The red lines provided cues that 
helped the users to identify the aircraft that were in con- 
flict as well as providing conflict geometry information. 
Due to software constraints, the addition of the red conflict 
lines, which had to be drawn at a top level, revealed 
a significant design limitation in the number of colors 
available for use in the PGUI. Only three top colors had 
been specified to the PGUI and none of them were red. 

A lengthy software fix was implemented to respecify the 
top gray color to red as a CPTP specific PGUI run time 
option. This was an interim measure pending a redesign of 
the color infrastructure. 

February 1997 

Conflict resolution enhancement (5b)- The CTAS CPTP 
functionality was initially limited to producing only one 
trajectory per aircraft so that all trial resolutions were 
conducted using active trajectory inputs. The active inputs 
for speed and altitude were complex but manageable, as 
long as the user followed the right sequence. The user 
inputs required to examine various routing changes were 
disordered and quite unmanageable. For this reason, the 
redesign process began with a focus on the routing 
functionality needed for planning a direct waypoint or 
vectoring maneuver. A direct waypoint maneuver consists 
of sending an aircraft direct to a waypoint in the filed route 
of flight. A vector maneuver consists of giving an aircraft 
a heading off the filed route of flight and then having the 
aircraft rejoin the filed route of flight at either a waypoint 
in the filed route or an auxiliary waypoint that is created 
by the system. 

The first change to the CPTP vector trial plan function- 
ality included a simplification and linking of the capture 
waypoint and auxiliary waypoint functions used to vector 
aircraft. Additionally, the user input process for vectoring 
an aircraft was greatly simplified. The purpose for these 
initial changes was to link functionalities that were con- 
ceptually related and to take a first step in the evolution of 
a trial planning functionality. 


The new functionality allowed the user to dwell on an 
aircraft symbol and type “Ctrl-a” to generate a flight plan 
route (green) and a profile selector (PFS) route (white) that 
was drawn from the aircraft to the default VOR (very high 
frequency omnidirectional radio range). The PFS route is 
the CTAS predicted route that is used for conflict pre- 
diction. The flight plan and PFS routes are shown in 
figure 4. 

A white box appeared around the default capture waypoint 
VOR to facilitate identification of the default waypoint 
being used by the system (fig. 5). If the default waypoint 
was off screen, the box appeared at the edge of the screen 
with a text notation indicating that the default VOR was 
off screen. To change the default VOR, the user entered a 
new three letter identifier in a scratchpad. 

An auxiliary waypoint (white asterisk) was created with a 
left mouse click on the PFS route. A center mouse click 
was used to drag the new auxiliary waypoint to desired 
position (fig. 6). The system was able to update the route 
quickly enough to provide a rubber band effect in the 
construction of a trial route. The user was able to exit the 
auxiliary waypoint mode with a dwell and left click on the 
aircraft. 

March 1997 

Conflict resolution enhancement (5a, b)- The CTAS 
CPTP system was initially limited to the construction of 
one PFS route per aircraft. This limitation resulted in an 
inability to display the active trajectory during trial 
planning. The loss of active trajectory situation awareness 
was not considered to be acceptable, and engineering 
redesign to provide dual trajectory capability was required. 

A new multitrajectory capability was designed and 
implemented by the engineering team that allowed the 
system to display both a trial plan trajectory that could be 
manipulated by the user and the active aircraft trajectory 
that displayed the actual position of the aircraft. Trial plan 
graphics were developed for altitude, speed, and vector 
changes using the new multiple trajectory capability. In 
addition to the multiple trajectory graphics, a panel was 
developed for use in trial planning inputs. This prelimi- 
nary attempt at a “real” trial planning functionality 
allowed for situation awareness of the active trajectory 
while in trial planning mode and was the second large step 
in the evolution of the functionality. 

The user entered trial plan mode by dwelling on the 
aircraft to be trial planned and typing “shift-t.” The trial 
plan panel, shown in figure 7, would appear next to the 
aircraft. The trial plan panel allowed the user to trial plan 
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and then implement a conflict resolution using vector, 
speed, and altitude changes. 

A vector trial plan was accomplished by pulling up the 
Trial Planning panel and left clicking on the vector button 
of the Trial Planning panel to display the aircraft’s red 
PFS and green flight plan route lines along with a yellow 
trial planning PFS route line. We again encountered color 
limitations and the yellow routes were constructed by 
dithering red and green. 

To change the default VOR, the user had to left click in 
the text-entry field by VECTOR and type in the identifier 
of the desired waypoint, then left click on the VECTOR 
button as shown in figure 8. 

An auxiliary waypoint was added by left clicking along 
the yellow PFS route (trial planning route). A center click 
and drag was used to position the auxiliary waypoint in 
the desired location. If the trial plan conflict list showed 
the conflict resolved with a new plan, it could be accepted 
with a left click on the trial plan panel Accept button. 
Upon acceptance, the yellow trial plan trajectory turned to 
white, denoting an active trajectory, and the old active 
trajectory was no longer displayed. To reject a trial plan, 
the user left clicked on the Reject button, which also 
exited trial plan mode. To try another trial plan, the user 
left clicked on the Clear button. 

To initiate speed trial plan, the user left clicked on the 
speed button (+/- KIAS) of the trial planning panel and 
entered a trial plan speed value indicated as + or - from the 
current speed. The trial plan value was displayed in yellow 
on the fifth line of the trial plan aircraft’s flight data block 
as shown in figure 9. 

To perform an altitude trial plan, the user left clicked on 
Alt to activate the trial plan. The trial plan altitude value 
was entered in the trial planning panel and displayed in 
yellow on the fifth line of the trial plan aircraft’s flight 
data block shown in figure 10. 

Conflict resolution enhancement (5c)- Initially, there 
was no easy way for the user to determine whether a 
predicted conflict in an active trajectory had been resolved, 
as the user had to monitor the conflict list and note when 
separation criteria had been met. The initial solution was 
to put an “R” for resolved in the time slot of the conflict 
prediction list. The “R” proved to be a good preliminary 
fix, but something more salient was required for a better 
graphical representation of trial plan resolution status. For 
that reason, a Trial Conflicts list was designed as shown 
in figure 1 1 to allow the user easy access to resolution 
information. 

PGUI CPTP user manual (9a)- The original PGUI user 
manual was found in the initial human factors evaluation 


to be outdated and inaccurate. An effort was begun to 
incorporate the CPTP functionality and PGUI setup 
parameters into a CPTP User’s Guide. Release 1.0 of the 
Conflict Prediction and Trial Planning User’s Guide was 
completed on March 31, 1997 (ref. 2). 

April-May 1997 

Conflict resolution enhancement (5a, b)- As trial 
planning functionality was tested and evaluated by human 
factors, engineering, and end user teams, there was a 
strong consensus reached that the functionality had to 
evolve to a point and click interface that would remove the 
end user’s hands from the keyboard. 

The point and click functionality was to be accessed 
through the relevant fields on the aircraft’s flight data 
block. This removed the need for the trial planning panel 
and related keyboard inputs. 

Access to the trial plan vector mode was made via a dwell 
and right click on the callsign located on the first line, 
first field of the aircraft’s FDB. Altitude trial plans were 
accessed via altitude information on the second line, first 
field of the FDB. Speed trial plans were accessed via the 
speed information located on the third line, second field of 
the FDB. Additionally, flight plan information (not 
strictly speaking a trial plan function) was accessed via the 
aircraft’s sector identifier number located in the first line, 
second field of the FDB. 

All trial planning was accomplished with point and click 
graphics and pop-up menus which provided text, graphics, 
and color cues regarding the trial plan modes and status. 
Trial planning mode information was provided in yellow 
text on the fifth line of the FDB. 

Upon accessing the Vector trial planning capability, a 
Vector menu pop-up would appear asking the user to 
select “change capture waypoint” option, “auxiliary 
waypoint” option, or reject (to exit). (This first menu 
pop-up proved to be an unnecessary extra step and was 
soon deleted.) The next menu pop-up (which soon became 
the first menu option box) enabled the user to select a 
capture waypoint. The system defaulted to the next VOR 
in the aircraft’s flight plan and the user selected an 
alternative if desired. A yellow “V” appeared in the fifth 
line of the trial plan aircraft’s FDB to indicate that the 
aircraft was in Vector trial plan mode as seen in figure 12. 

The user was then able to determine whether sending the 
aircraft “direct to” that new VOR would resolve the pre- 
dicted conflict. If the Trial Conflicts list showed that this 
maneuver would solve the problem, then the user could 
use the new heading and time advisories provided (in green) 
next to the aircraft symbol and issue them as a clearance 
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to the aircraft. After issuing the clearance they could then 
accept, and hence activate, the change to the aircraft’s route 
of flight by left clicking on the yellow “V.” 

If the “direct to” vector mode trial plan did not provide a 
resolution for the conflict, an auxiliary waypoint could be 
used to build a new route for the aircraft that would solve 
the conflict. After the default VOR has been chosen, left 
clicking anywhere on the red PFS route would create an 
auxiliary waypoint. The user could then middle click and 
drag the auxiliary waypoint until the PFS route changed 
to yellow, indicating a conflict free route as shown in 
figure 13. The controller could then issue the provided 
heading and time to turn back to the filed route of flight as 
a clearance to the aircraft. 

When the altitude trial plan functionality was accessed, an 
altitude trial plan box appeared with the aircraft’s current 
altitude highlighted as the default and all other possible 
altitudes listed above and below it as shown in figure 14. 
An altitude for trial planning was selected by left clicking 
on the desired altitude in the list. When a trial plan 
altitude was selected, the letters “TP” and the selected 
altitude appeared in yellow on the fifth line of the FDB as 
seen in figure 15. 

When the speed trial planning functionality was accessed, 
a speed trial plan pop-up appeared with a list of speed 
modes (Ascent IAS, Descent IAS, Cruise IAS, Cruise 
MACH) as seen in figure 16. Left clicking on the desired 
speed mode produced a speed +/- IAS or MACH value 
box shown in figure 17. The trial plan +/- IAS or MACH 
speed (indicate +/- from current speed, i.e., +30 or -30) 
was selected by left clicking on the desired value. The 
current “active” indicated airspeed and the new trial plan 
input value +/- were displayed in yellow on the fifth line 
of the flight data block as shown in figure 18. 

June 1997 

Enhanced software infrastructure to provide increased 
color capability (lg)- Software and hardware limitations 
were experienced as the PGUI design requirements began 
to demand extensive color capability. The CTAS software 
graphics development team redesigned the system color 
infrastructure using a double buffering scheme that 
extended the system color capability to 127 colors and 
simultaneously eliminated the three level color scheme. 
Additionally, an interface was designed to provide 
researcher access to the color parameters for each of the 
PGUI elements. The ability to easily respecify the red, 
green, blue, and brightness values of each PGUI element 
is crucial for any color effort. The new color infrastructure 
provided the extended color capability needed to address 
elements la-f of the human factors evaluation. 


Controller evaluation of the CPTP PGUI— An informal 
end user evaluation was conducted at this point in the 
PGUI design process. Three air traffic controllers repre- 
senting FAA Headquarters, Boston ARTCC, and Fort 
Worth ARTCC were asked to use and evaluate the CPTP 
PGUI functionality during a two day period. The con- 
trollers also evaluated the training materials and user’s 
guide that were being developed concurrently with the 
PGUI. 

Design suggestions were sorted into three categories: 
changes to make immediately in preparation for field test, 
longer term redesign changes to existing functionality, and 
completely new functionality. The design suggestions are 
listed below along with whether they were immediate 
changes (I), redesign of current functionality (R), or 
completely new functions (N): 

1 . The default capture waypoint for arrivals should be 
the meter fix. The default capture waypoint should 
always be beyond the predicted conflict point. (I) 

2. When vector trial plan is selected by clicking on the 
aircraft callsign, the initial pop-up window should be 
deleted from the design and the capture waypoint list 
should be displayed with the default capture waypoint 
highlighted. A reject button should be included at the 
top of the list. (R) and (I) 

3 . The conflict aircraft callsign for a trial plan, which is 
currently displayed on the forth line of the FDB, 
should be deleted. (R) (Note: restored later after further 
consideration.) 

4. When a conflict is resolved and “R” appears in 
conflict prediction list, the conflict aircraft callsign in 
the fourth line of the FDB should be removed. (N) 
and (I) 

5 . The conflict probability color coding in the conflict 
list should be user selectable from the F9 Conflict 
Probe setup panel so that color coding may be turned 
off if desired. (N) 

6. Infrastructure and PGUI panel should be colored to 
allow the following: 

a. Aircraft not owned or in conflict should have a 
low conspicuity relative to conflict aircraft. (N) 

b. Aircraft not owned or in conflict should have a 
limited data block (altitude only). (N) 

c. New aircraft symbols that show direction should 
be incorporated. (N) 

d. Red, yellow, and green colors should be reserved 
for conflict status. (R) 
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e. Route lines for trial plan should be displayed as a 
thick white line. (R) 

f. Flight plan route should be displayed in gray. (R) 

e. Conflict aircraft and corresponding FDBs should 
have a conspicuous color relative to nonconflict 
aircraft. (N) 

7. Access should be provided to conflict graphic display 
through line 4 of data block consistent with the rest 
of the point and click functionality. (N) 

8. Global trial plan should be clear (clear whole screen 
of all trial plans via keyboard input). (N) 

9. Capability to dwell and click on all PGUI elements 
that are not part of trial plan function should be 
turned off when in trial planning mode. (R) 

10. Flight plan route should not be displayed when a trial 
plan is activated. (R) 

1 1. In line 1, field 2 of data block, sector number should 
be replaced with destination airport three letter 
identifier. (R) and (I) 

July 1997 

PGUI CPTP training material developed (9b)- 
Development of the Conflict Prediction and Trial 
Planning tool training packet to be used for training air 
traffic controllers at Ames and at the Denver ARTCC 
was completed. 

National Air Traffic Control Research Institute (NARI) 
controller evaluation of the PGUI - A second evaluation 
of the CPTP PGUI was conducted with input provide by 
NARI controllers from New York ARTCC, Chicago 
ARTCC, Houston ARTCC, and Los Angeles ARTCC. 

The controllers participated in one day of training on the 
use of the Conflict Prediction and Trial Planning tool 
followed by one day of simulations and evaluations. 
Design suggestions were again broken down into three 
categories: changes to make immediately in preparation 
for field testing of the CPTP functionality (I), longer 
term redesign changes to existing functionality (R), and 
completely new functionality (N). The PGUI design 
comments and suggestions were as follows: 

1. It was difficult to transition between the use of the 
conflict list and the conflict graphics. Provide access 
to the conflict graphics via the conflict aircraft 
callsign in the fourth line of the FDB. (N) and (I) 

2. It was difficult to determine whether an aircraft was 
in conflict with more than one other aircraft. The 
system needs to provide explicit information (text or 


graphics) about all aircraft that a single aircraft is in 
conflict with. (N) 

3. There is too much clutter when all conflict aircraft 
data blocks are displayed. The system needs to 
provide a way to dim or suppress conflict data 
blocks. (N) 

4. The flight plan amendment panels need to be 
redesigned into a single panel and should provide 
feedback to the user when flight plan amendments 
are made. (R) 

5. Do not use “V” for vector in trial plan, it means 
VFR. (R) and (I) 

6. Display all heading advisories in a three digit format 
(standard nomenclature). (R) 

7. Place aircraft callsign on the route lines for ease of 
identification. (N) 

8. Remove altitude information from the conflict list. 

It is not used and it is confusing. (R) 

9. The accept function on trial plans needs to be easier 
and quicker to use. (R) 

10. If an aircraft is “close” to the next waypoint in its 
route of flight, make the default capture waypoint the 
fix after rather than the next one. (I) 

11. In the conflict list always round down to four miles if 
the separation is not five miles. (R) and (I) 

12. Display conflict probe parameters (F9 setup panel 
information) on conflict prediction list for situation 
awareness purposes. (N) 

August 1997 

The design changes that were actually incorporated in 

preparation for the CPTP Field Test are listed below: 

1. The default capture waypoint for arrival aircraft was 
specified as the meter fix. 

2. The default capture waypoint was always specified 
beyond the point of conflict. 

3. The initial pop-up window for vector trial planning 
was deleted from the design and the capture waypoint 
list displayed immediately with the default capture 
waypoint highlighted. A reject button was also 
included at the top of the list. 

4. When a conflict was resolved and “R” appeared in the 
time to go field in the conflict prediction list, the 
conflict aircraft callsign in line four of the FDB was 
removed. 
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5. The conflict probability color coding in the conflict 
list was made user selectable from the F9 Conflict 
Probe setup panel. 

6. The conflict graphic display was made accessible 
through point and click functionality via the fourth 
line of the FDB. 

7. A global trial plan clear function was implemented 
using a “shift-t” input. 

8. The sector number in line 1, field 2 of the FDB was 
replaced with the destination airport three letter 
identifier. 

9. The “TP” text label was used for all trial plan 
modes. 

10. All of the heading advisories provided by the 
system were displayed in full three digit standard 
nomenclature. 

11. The time and distance components of the Conflict 
Prediction list were displayed rounded up to the five 
mile critical separation value as shown in figure 19. 

PGUI CPTP user manual enhanced (9a, b)- CPTP User 
Manual Release 1.0 was updated with all the new software 
and functionality changes and Release 2.0 was released for 
printing. 

There are ongoing updates and addenda to the current 
Release 2.0 of the Conflict Prediction and Trial Planning 
User’s Guide (ref. 3). There is also ongoing development 
of quick reference guides and training materials to serve as 
an adjunct to the user manual. 

PGUI CPTP training material developed (9b)- A 
CPTP training packet was completed for use in training 
air traffic controllers at the Denver ARTCC who were 
scheduled to participate in the CPTP field study. 

Proposed PGUI Design Changes 

Color Redesign of PGUI (la-g) 

Development of a new color design for the PGUI was 
enabled by the implementation of the double buffer color 
infrastructure. 

Some suggestions to be considered in a redesign of use of 
color on the PGUI are as follows: 

1. A general philosophy of color use should be articu- 
lated prior to the beginning of the design process so 
that color use will be consistent throughout the 
display. A standard philosophy of color use in 
displays is that of color defined visual layers. The 
layers are defined by variation in color contrast, hue, 


saturation, number, and size of similarly colored 
features. If the color factors defining layers are 
manipulated correctly, the user will tend to group the 
appropriate objects in a layer. For air traffic control 
displays, a back layer might consist of a sector map 
and related static information displayed in low satura- 
tion colors of similar hue. A middle layer might 
consist of aircraft, data blocks, and related dynamic 
information in a more conspicuous color range than 
the back layer. A top layer might consist of alerting 
information in the most conspicuous color range. 

2. Color should be used with care, as improper use of 
color can lead to eye strain, optical illusions, and cue 
confusion that can result in operator errors. A few 
basic principles are listed below: 

a. Use of saturated blues and reds: Shorter wave- 
lengths of light (blue) are refracted more than 
longer wavelengths of light (red) as they enter the 
eye. As a result, reds and blues are brought into 
focus at different points within the structure of 
the eye. Constant refocusing is therefore 
necessary to resolve reds and blues, and this can 
lead to eye strain. 

b. Use of contrasting colors: Color contrast can 
result in figure ground illusions, particularly 
when using bright, highly saturated colors. 

c. Color sensitivity: The human eye is more sensi- 
tive to colors in the yellowish green portion of 
the spectrum than to reds and blues. As a result, 
saturated greens and yellows will appear to be 
brighter (hence more conspicuous) than saturated 
reds and blues. Blue has a particularly low 
subjective brightness. 

d. Use of color with lettering: Dark lettering on a 
light background is more legible than light 
lettering on a dark background. 

e. Color discrimination: Small changes in green 
and yellow are easier to detect than small changes 
of red or blue. 

f. Color and peripheral vision: Reds and greens are 
not resolved in peripheral vision as easily as 
blues and yellows. 

g. Use of a variety of colors: The fewer the colors 
used the greater the impact on the user. 

h. Use of alerting colors: Alerting colors should 
only be used for alerting functions. 



Additional Functionality 

There are additional proposed design changes related to 
new functionality for the CPTP PGUI as follows: 

1. Incorporation of point and click functionality to 
provide easy access to PFS and flight plan routes for 
new aircraft entering the sector. 

2. Provision of user request “autoprobe” to monitor 
aircraft and allow delivery of request as soon as an 
aircraft is in conflict free status. 

3. Presentation of “hard” versus “soft” conflict status. 
Hard conflicts are those predicted where there is no 
clearance expected between an aircraft and the predicted 
point of conflict, and soft conflicts are those where 
there is a clearance expected that will result in a 
conflict. 

Global Display Commands (3a, c, e) 

There were design suggestions related to the implemen- 
tation of a button bar for global commands (some of 
which are currently driven from the keyboard and some 
of which are additional functionality), including trend 
vectors, trial plan clear, flight data block quick deconflict, 
strip management, range and bearing, future situation 
display, zoom/center, latitude/longitude of cursor, and 
track histories. 

Proposed Redesign of Selected Graphical Elements 

(If) Right data blocks to have backfill and borders 
identifying alert and planning status. 

(2a, 3b) Mouse inputs to be redesigned to use a standard 
of action method: left button for action (selection 
of specific menu items), middle button for move 
(drag), and right button for planning (access to 
menus). 


(3c) Aircraft track histories to be consistent with radar 
histories in shape and update rate. 

(3d) The aircraft symbol to be redesigned to a circle 
enclosing a triangular pointer giving aircraft 
direction. Rat track/free track information to be 
made available through the flight data block. 

(3e) Zoom and centering functionality to be 

redesigned. The current zoom and centering 
functionality is quite crude and can easily result 
in disorientation of the display. 

(5c) Trial plan routes to be drawn thicker. 

(7a) Right plan amendment panel to be redesigned to 
provide support for trial planning and active 
inputs and possibly extend to provide total paper 
strip replacement. 
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Figure 1. Conflict aircraft callsign displayed in the fourth 
line of the flight data block. 
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Figure 2. Conflict list panel. 
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Figure 3. Conflict lines from aircraft to the point of first loss of separation. 



Figure 4. Flight plan route and PFS from a selected aircraft to the default VOR in the filed route of flight. 
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Figure 5. White box identifying the default waypoint being used by the CPTP. 



Figure 6. Construction of a trial route through an auxiliary waypoint. 



Figure 7. Trial planning panel for user inputs to trial planning functionality. 






Figure 8. Vector trial planning using the trial planning panel for user inputs. 



Figure 9. Trial planning of a conflict resolution using a change in speed of an aircraft. 





Figure 10. Trial planning of a conflict resolution using a change in altitude of an aircraft. 



Figure 1 1. Conflict prediction list for trial planning trajectories. 



Figure 12. Aircraft in Vector trial plan mode. 
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Figure 13. A conflict free trial plan route using an auxiliary waypoint. 



Figure 14. Aircraft in Altitude trial plan mode. 
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Figure 15. Display of a trial plan for changing an aircraft's altitude. 
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Figure 16. Trial plan speed modes. 


Figure 1 7. Trial plan speed values. 
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Figure 18. Display of a trial plan for changing an aircraft’s speed. 
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Figure 19. Time and distance values displayed as whole number rounded up to the critical five mile value. 
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